A content/media delivery network (CDN/MDN) has emerged in the conventional art, delivering website contents from a source node to an edge node closest to a user so that the user may obtain desired contents proximately, thus increasing the response speed when the user visits a website. For multimedia content, such as video on demand (VoD) and live video, because video contents are transmitted in real time and large volumes, delivering video content to an edge node closest to a user assures better quality of play for the user and significantly reduces impact on the backbone network.
The structure of a CDN/MDN in the conventional art is shown in FIG. 1. The CDN/MDN includes:
a global server load balancer (GSLB), adapted to schedule a media content request of a user to an edge node closest to the user;
a server load balancer (SLB), responsible for routing the content requests of local users, balancing loads, and selecting a best media server (MS) according to the content distribution and device load conditions, and
a media manager (MM), adapted to deliver media contents and schedule MSs between the center and edges, between edges and within an edge node.
In the CDN/MDN structure shown in FIG. 1, because the MS bandwidth is fixed in an edge node, the edge node may only serve a limited number of users. To satisfy users' needs, the capability of an edge node needs to increase linearly with the growth of users. Thus, for the CDN/MDN structure in the conventional art, huge investments are required in an edge node. Because service requests of a user are indefinite, even though the system capability of the edge node is increased, it is difficult to fully meet all abrupt rises of user requests. As a result, once the number of concurrent user requests in an area exceeds the maximum capacity of the network, the network may only reject the service.
At present, many pure peer to peer (P2P) steaming software systems are already available on the Internet. A common feature of these systems is that they are able to set up mutual aid relations between clients via a scheduling module in the network. Streaming servers in the network provide only a few streams and clients (peer nodes) deliver streaming data to each other by means of the above mutual aid relations so that a large number of clients may watch streaming programs at the same time. The scheduling module does not record topology relations of node networks, and the peer nodes help each other in a best-effort way. The inventor finds that the P2P streaming software system in the conventional art does not appear to consider geographic issues, which may result in a large volume of traffic across backbone networks. Moreover, because the scheduling module does not record the topology relations of node networks and does not provide unified resource scheduling, data delivery basically relies on the mutual aid of nodes. Therefore, channel switching may take a long time and programs of large streams may be difficult to support. In addition, the unsteady nodes and the best-effort help mode may also result in unstable playing of programs.
In conclusion, the streaming system based on client/server mode in the conventional art causes a heavy load on the MS, whether in center mode or center-edge distribution mode. The capability of the MS determines the number of users that are served at the same time. Thus, to meet the streaming application requirements of a large number of users, streaming service providers must pour huge investments in the server. For streaming live services based on P2P technology, because the server has limited resources and may provide only few streaming data and most of nodes rely on the upload capabilities of other nodes to watch video programs, it is difficult to guarantee the quality of service (QoS). In addition, due to limitation of upload capabilities, the P2P technology cannot provide live programs at a high bit rate.